CiliumNetworkPolicy つらみ集

前提として ingress または egress に対してデフォルトで全て不許可にするルールを適用しているものとします

CiliumNetworkPolicy で指定するtoPortsは Service のポートではなく Pod が公開しているポート

ポートに名前を付けていない場合意味不明になる

これがコントローラが生成したものだった場合……(泣)

kubelet のポートフォワードやヘルスチェックを通すためにはホストからの通信を許可する必要がある

よく考えれば当たり前ではあるが

kube-apiserver からの通信が、Konnectivity を使ってワーカーとコントロールプレーンを分離している構成では Konnectivity Agent から来る(ように見える)

Cilium で言うところのkube-apiserver entity は ingress だと使えないということ

egress だと使えるという罠

Konnectivity Agent のデプロイ方法によってどこから来るのか変わる

hostNetwork: trueにすると Cilium で言うところの hostもしくはremote-nodeになる

remote-nodeからも来るというのがポイントで、上述の理由によりhostからは全部許可することになりがちなので、確率的に Webhook が成功して謎になる

hostNetwork: falseでは Pod IP が付与されるのでそこからの ingress になる

kubelet はホストローカルで動いているので明示的に Agent からの通信を許可する必要がある

Cilium のドキュメントにも書いてあるが、普通に難しすぎるのでkube-apiserver entity が付く条件を制御させてほしい

Ingress/Gateway の実装詳細が漏れる

L7 プロキシは Source IP を保持しないので、どこでプロキシするかでバックエンドの NetworkPolicy の ingress 条件が変わる

ALB や Cloud LB ならクラスタ外(world)

Source IP の CIDR で制御する

オンプレ環境でクラスタ内に L7 プロキシがある場合、その Pod から来る

L7 プロキシ Pod へのworldからの ingress 許可も必要

オンプレ環境で Cilium の Envoy を使う場合、ingress entity から来る

Envoy (ingress) への world からの ingress 許可も必要

これらの記述が全てのバックエンドに必要というのが厳しいポイント

Ingress や HTTPRoute から頑張れば自動生成できそうとはいえ……

普通に難しすぎるのでingress entity またはなんか適当な名前の entity を定義する手段が欲しい